Configuring Your App for Release

With all the necessary materials gathered, let’s start configuring your app for release. This step involves making some configuration changes to the source code, resource files, and app manifest. Some of these steps are optional, but highly encouraged as good coding practices.

Follow these steps (All steps listed below have been taken from the Configuring Your Application for Release section of the Prepare for Release guide):

Choose a good package name

Make sure you choose a package name that is suitable over the life of your application. You cannot change the package name after you distribute your application to users. You can set the package name in application's manifest file. For more information, see the package attribute documentation.

Turn off logging and debugging

Make sure you deactivate logging and disable the debugging option before you build your application for release. You can deactivate logging by removing calls to Logmethods in your source files. You can disable debugging by removing the android:debuggable attribute from the tag in your manifest file, or by setting the android:debuggable attribute to false in your manifest file.
Also, remove any log files or static test files that were created in your project.

Also, you should remove all Debug tracing calls that you added to your code, such as startMethodTracing() and stopMethodTracing() method calls.

Clean up your project directories

Clean up your project and make sure it conforms to the directory structure described in Android Projects. Leaving stray or orphaned files in your project can prevent your application from compiling and cause your application to behave unpredictably. At a minimum you should do the following cleanup tasks:

• Review the contents of your jni/, lib/, and src/ directories. The jni/ directory should contain only source files associated with the Android NDK, such as .c, .cpp, .h, and .mk files. The lib/ directory should contain only third-party library files or private library files, including prebuilt shared and static libraries (for example, .so files). The src/ directory should contain only the source files for your application (.java and .aidl files). The src/ directory should not contain any .jar files.

• Check your project for private or proprietary data files that your application does not use and remove them. For example, look in your project's res/ directory for old drawable files, layout files, and values files that you are no longer using and delete them.

• Check your lib/ directory for test libraries and remove them if they are no longer being used by your application.

• Review the contents of your assets/ directory and your res/raw/ directory for raw asset files and static files that you need to update or remove prior to release.

Review and update your manifest and Gradle build settings

Verify that the following manifest and build files items are set correctly:

• element. You should specify only those permissions that are relevant and required for your application.

• android:icon and android:label attributes. You must specify values for these attributes, which are located in the element.

• android:versionCode and android:versionName attributes. We recommend that you specify values for these attributes, which are located in the element. For more information see Versioning your Application

There are several additional manifest or build file elements that you can set if you are releasing your application on Google Play. For example, the android:minSdkVersion and android:targetSdkVersion attributes, which are located in the element. For more information about these and other Google Play settings, see Filters on Google Play

Address compatibility issues

Android provides several tools and techniques to make your application compatible with a wide range of devices. To make your application available to the largest number of users, consider doing the following:

• Add support for multiple screen configurations: Make sure you meet the best practices for supporting multiple screens. By supporting multiple screen configurations you can create an application that functions properly and looks good on any of the screen sizes supported by Android.

• Optimize your application for Android tablet devices.: If your application is designed for devices older than Android 3.0, make it compatible with Android 3.0 devices by following the guidelines and best practices described in Optimizing Apps for Android 3.0.

• Consider using the Support Library: If your application is designed for devices running Android 3.x, make your application compatible with older versions of Android by adding the Support Library to your application project. The Support Library provides static support libraries that you can add to your Android application, which enables you to use APIs that are either not available on older platform versions or use utility APIs that are not part of the framework APIs.

Update URLs for servers and services

If your application accesses remote servers or services, make sure you are using the production URL or path for the server or service and not a test URL or path.

Implement Licensing (if you are releasing on Google Play)

If you are releasing a paid application through Google Play, consider adding support for Google Play Licensing. Licensing lets you control access to your application based on whether the current user has purchased it. Using Google Play Licensing is optional even if you are releasing your app through Google Play.

For more information about Google Play Licensing Service and how to use it in your application, see Application Licensing.